IBIS Macromodel Task Group Meeting date:01 June 2021 Members (asterisk for those attending): Achronix Semiconductor Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis Jared James Google: Zhiping Yang Intel: Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao * Radek Biernacki * Ming Yan Todd Bermensolo * Rui Yang Luminous Computing * David Banas Marvell Steve Parker Micron Technology: Randy Wolff * Justin Butterfield Missouri S&T Chulsoon Hwang Siemens EDA (Mentor): * Arpad Muranyi SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Walter to add diagrams for the normal reference flow and send out BIRD211.2_draft9. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the May 25th meeting. Ambrish moved to approve the minutes. Walter seconded the motion. There were no objections. ------------- New Discussion: BIRD211.2 draft 9: Arpad noted the email he had sent summarizing the state of the discussions. He said he thought that as discussions went on, we kept forgetting about some of our requirements. This led us to keep going around and around. Arpad repeated the two requirements he had observed and noted in his email: #1: No changes should be required for terminal models (initial Tx and final Rx) #2: We should be able to use the same Tx and Rx models as terminal models and as Redriver models. Ambrish said a model could satisfy #2, but he wasn't sure we needed to mandate it. Fangyi said #2 was really a side effect of Walter and Radek's goal to have the same specifications for a terminal Tx or a Redriver Tx. Radek said the original point was that they didn't want to have a special type of Tx that is for Redrivers only (which would have been the case if Tx_Impulse_Input were only allowed for Redriver Tx models). In the BIRD as written, the Redriver Tx would be included in a [Repeater Pin] keyword, but that does not prohibit the same model from being used as a terminal Tx as well. Fangyi said the specification should allow #2 but not require it. The group agreed with this, and the group accepted both of the requirements Arpad stated. Walter said he would add them to the Solution Requirements section of the BIRD, per Arpad's suggestion. Walter referred to his email in reply to Arpad's email on the state of the discussions. He said a model should represent in simulation what the hardware does. Ambrish objected that this requirement would mean there could be no such thing as a statistical model. Walter said he meant the model should represent what a device does in hardware, not necessarily emulate how it does it. A model could provide extra features not found in the hardware in order to help with making engineering decisions. For example, a Tx model might provide adaptation, but if the hardware didn't then the Tx model should also provide a mode without adaptation that simply uses specified tap coefficients. For another example, a memory vendor's actual DDR5 Rx hardware would not have the ability to optimize itself, but the model could provide an option to adapt to help the system designer make engineering decisions. But, such a model should also provide a fixed mode that does not adapt. Ambrish said this was veering into a discussion of what is a good model and what is a bad model. He said this discussion could be endless, and the specification should simply define the API and not go into what constitutes a "good" model. Walter said he was trying to correct a mistake he thought we had made 12 years ago. He said with IBIS 7.0, there's no way for a model maker to state whether their Tx model is adapting or not (meaning there's no Reserved Parameter that allows the model maker to advertise the behavior). Ambrish said there was no reason that the tool needed to know this information given the IBIS 7.0 flows. Walter said that if Tx_Impulse_Input can be used for all Txs, then it provides the way for model makers to advertise this behavior for AMI 7.1 Tx models. Because there was some confusion, Walter addressed the parameter example he had given at the end of his email. He said that he had provided an example of a possible solution if Tx_Impulse_Input had been restricted to Redrivers. His example showed the parameter renamed to include "Redriver" in the name. It also showed an additional parameter (Tx_Adapts), which could have been introduced and used with terminal Tx. However, since we agreed that Tx_Impulse_Input can apply to all Txs, this example is not necessary. Ambrish said he was concerned about mission creep. He said the name of the BIRD was "New Redriver Flow". Walter agreed that it was a bit of mission creep, but since Tx_Impulse_Input gives the model maker a way to specify that their Redriver Tx does or doesn't optimize, why not extend that to regular Txs too? If the Tx_Impulse_Input can apply to all Txs, then we've given the model maker a way to specify whether or not their Tx optimizes. Arpad returned to his original summary and the two requirements we'd agreed upon. He said these requirements mean we can't go with Bob's earlier proposal to limit Tx_Impulse_Input to repeaters. Bob agreed and said the straw vote at last week's meeting resolved that we weren't restricting it to repeaters. He said Walter had instead added some new figures for the normal flow and made the BIRD a bit more broad. Bob noted that he had been taking the name of the BIRD literally ("Redriver") when making his first proposal. He said it's now effectively defining new flows altogether. Walter agreed that the title of the BIRD could be changed. Walter said he'd added new block diagrams depicting the normal (single-channel) flow given the various settings of Tx_Impulse_Input for the Tx. He had also added new text to describe the flows and block diagrams. However, he had not actually changed the simulation flow. Arpad said his understanding was that changes in the descriptions of the flows, other than the Redriver flow that is being fixed, were only made to incorporate this new parameter that could now appear. But the flows themselves were not changed. Walter reviewed his diagrams and proposed new text for the single-channel reference flow. Bob and Ambrish suggested removing all language related to versions, e.g., "documented in IBIS 7.0" or "AMI Version 7.1 and later...", etc. The group agreed. All such language was removed, and the various flows were tied to whether or not Tx_Impulse_Input was specified and what its value was if it was specified. Radek suggested naming the three different flow options Flow 1, Flow 2, and Flow 3 and referring to them that way to be precise. Walter agreed and said he would add those names to the block diagrams too. Ambrish said we should be careful to distinguish between the statistical and time domain flows. Walter noted that his rewrite had introduced the term "initialization flow", after which you could then proceed with statistical or time domain simulation. He said he thought it resulted in an improved description of what Init and GetWave do. He asked people to read it carefully and comment. Arpad said he thought we were finally down to wordsmithing and had moved beyond technical flow questions. - Curtis: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. AR: Walter to send out BIRD211.2_draft10 with today's changes. ------------- Next meeting: 08 June 2021 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives